Database management systems (DBMS) can be classified as either record-based systems or object-based systems. Both forms of DBMS's typically enlist a data “model” to describe data as well as that data's structure, relationships, and constraints within a database. Data models are also referred to as metadata models since they store metadata, or data about the composition of data in a database in order to describe the manner in which data is structured within a database.
One type of metadata model frequently employed In Business information (BI) systems is a metadata reporting model that includes a set of database information that has been packaged for use in the reporting component of the BI system. Unfortunately, metadata reporting models have generally been developed on an ad hoc basis over time in order to meet the particular needs of a specific group of users. Thus, prior art methods for making changes to targeted sources of data within a metadata model have necessitated the writing of customized program logic to re-target a given report at a different datasource in response to a new set of reporting requirements.
In conventional reporting models, a data model designer typically first creates a logical design. After that logical design has been completed, the designer then establishes a physical design that reflects how data is to be represented in a database. The designer subsequently creates a corresponding storage scheme, or in other words the structure that a database takes. “Hard-coded” mappings between the metadata model and a datasource are then provided within that metadata model.
The problem is that these prior art reporting models use undesirably rigid methods of mapping a datasource against a report. As such, existing metadata models are incapable of retrieving data from a different datasource without having to re-write program logic. This presents significant difficulties since a typical user has little or no knowledge of the underlying program logic, let alone any capacity to re-write mapping logic. The result is a “disconnect”, as the process is taken out of the user's workflow while the user awaits completion of code rewrites to make the necessary changes.
What is needed is a metadata model that allows for the retrieval of data from differing datasources “on-the-fly”, and in a more user-friendly manner without the need to re-write customized code.
For the foregoing reasons, there is a need for an improved method and system for mapping datasources in a metadata model.